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CLAIM FOR PRIORITY 
This application is a national stage of PCT/EP2004/Q51153 
which was published on January 13/ 2005 and which claims 
the benefit of priority to German Application No. 
15 10327610.6 filed June 18, 2003. 



TECHNICAL FIELD OF THE INVENTION 
The invention relates to a method and device for forming 
an encrypted message, and to a method and device for 
20 encrypting an encrypted message. 



BACKGROUND OF THE INVENTION 
Whilst While accessing a network, a mobile radio 
communication terminal usually receives a series of 
25 configuration parameters from the communication network, 
including for instance communication connection 
parameters. The mechanism used in providing the 
configuration parameters depends on the application 
scenario concerned . 

30 

For a mobile radio communication terminal that logs into 
a local network such as a wireless local area 
network (WLAN) , using for example what is known as a 
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hotspot as the access node to the local network, the 
option to provide configuration parameters is frequently 
not available at present, since neither point-to-point 
protocol (PPP) nor a virtual private network (VPN) are 
5 used. If there is no protection for the configuration 
data used by the mobile radio communication terminal 
concerned, that is to say, for the configuration 
parameters, a hacker has the opportunity to cause harm 
both to the mobile radio communication terminal and to 
10 the communication network. A description of the existing 
security threats can be found for example in [1] . 

Fig.l shows a block diagram of a communication system 
100. The communication system 100 has an access network 
15 101 and a network domain 102 which are coupled together 
by means of an access router 105. 

* 

Furthermore at least one mobile radio communication 
terminal 103 and a link node 104 are provided in the 
20 access network 101, in order to provide a mobile radio 

communication link between the mobile radio communication 
terminal 103 and the network domain 102 and from there to 
other communication terminals. 

25 Fig.l also shows a plurality of essential communication 
protocols which are executed in the context of a 
communication network access procedure. The single and 
double-ended arrows indicate in each case the entities of 
the communication instances concerned between which the 

30 respective communication protocol is executed. 

Thus a protocol for providing the communication network 
domains security is provided between the . communication 



PCT/EP2004/051153 / 2003P08757WOUS 

3 



network domain 102 and the access router 105, indicated 

i 

by a first arrow 106 (1. Network Domain Security in Fig. 
1) . 

5 Moreover a secure IP address configuration is provided in 
the context of a second communication protocol , shown in 
Fig.l by a second arrow 107 (2. Secure IP Address 
Configuration in Fig.l). 

10 An authentication and security association between on the 
one hand the mobile radio communication terminal 103 and 
the access router 105 and on the other hand between the 
access router 105 and the communication network domain 
102 is established by using the mobile radio 

15 communication terminal 103, the link node 104 and the 

access router 105, represented in Fig. 1 by a third arrow 
108 and a fourth arrow 109 (3. Authentication and 
Security Association Establishment in Fig.l). 

20 It is also usually the case that the communication 

protocols provided are situated at the layer 2 level of 
the open systems interconnection (OSI) reference model, 
that is, the layer -for providing security mechanisms at 
the level of the data security layer, indicated in Fig.l 

25 by a fifth arrow 110 between the mobile radio 

communication terminal 103 and the link node 104, or by a 
sixth arrow 111 for protecting the communication at the 
level of the data security layer between the link node 
104 and the access router 105. 

30 

A seventh arrow 112 represents a further communication 
protocol for providing security mechanisms at the level 
of the Internet protocol layer between the mobile radio 
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communication terminal 103 and the access router 105. 

Of particular significance throughout the present 
document are the communication protocols for ensuring 
5 secure IP address configuration (represented by the 
second arrow 107) and for authentication and security 
association establishment (represented by the third arrow 
108 and the fourth arrow 109) . 

10 A known method for the provision of configuration 

parameters in the context of business communication 
networks is to configure said parameters either 
statically or dynamically, for example according to the 
dynamic host configuration protocol for IPv6 (DHCPv6) , as 

15 described in [2] or [3] . 

Even in [2] and [3] there is no provision for 
cryptographic protection of the respective communication 
protocols they describe. However, DHCP offers the 
20 possibility , of securing electronic messages in the 
communication protocol by means of a previously 
negotiated cryptographic key. This possibility is 
described in [4] . 

25 At the present time point-to-point protocol (PPP) or a 

variation known as point-to-point protocol over Ethernet 
(PPPoE) is used almost exclusively for accessing an 
Internet service provider and transmitting the necessary 
configuration parameters to the mobile radio 

30 communication terminal. 

Known methods for accessing a virtual private network 
(VPN) involve using two protocols, namely a first 
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protocol ModeConfig and/or a second communication 
protocol DHCP, to transport the configuration parameters 
for a mobile radio communication terminal, that is, its 
configuration data, in a cryptographically protected 
5 manner. Said protocols are described in [5], [6], [7] and 
[8] . 

In the case of the ModeConfig communication protocol 
[lacuna] were integrated in the authentication and key 
10 negotiation protocol known as Internet key exchange 
(IKE), described in [9], and/or in the Internet key 
exchange v2 protocol (IKEv2), described in [10]. 

Different methods have been used in the past to enable 
15 the cryptographically protected transmission of 

configuration parameters between a communication network 
and a mobile radio communication terminal. 

These methods can be divided into three main groups: 

20 

1. Enhancements to DHCP: 

A series of enhancements to DHCP for the cryptographic 
protection of DHCP messages in the environs of mobile 
25 radio communication terminals have been proposed, as 

described for instance in [11], [12], [13] and [14]. 

These enhancements to DHCP are intended to enable a 
mobile radio communication terminal to dynamically 
30 establish in the communication network a security 

association with the DHCP server. 



2. Enhancements to the extensible authentication protocol 
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(EAP) method: 

The extensible authentication protocol is described in 
[16] . 

An enhancement to an EAP method is described in [15] . 
This is designed to enable the internet key exchange 
protocol v2, as described in [10], to be reused. 



10 As a side effect IKEv2 includes the ability to 

transmit configuration parameters in a 
cryptographically protected manner. 



3. Bootstrapping methods: 

15 

In a known proposal concerning a communication 
protocol, the initial network authentication is 
enabled by using EAP and providing a secure 
communication link to the DHCP server (cf. [17]). 

20 

The advantage of this method is the separation between 
the network authentication and the cryptographic 
security of the DHCP messages. 



25 In this case the DHCP communication protocol does not 

need to be modified. 



A method for EAP authorization is described in [18] . 



30 Further enhancements to the extensible authentication 
protocol for cryptographically secure data transmission 
are described in [19], [20] and [21]. 
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SUMMARY OF THE INVENTION 
The object of the invention is to resolves the problem of 
finding a simple way to provide cryptographically secure 
communication configuration data to a communication 
5 terminal. 

Thio object is achieved by ln one embodiment of the 
invention, there is a method and a device for forming an 
encrypted message, and— by a method and a device for 
10 encrypting an encrypted message with the fcaturco 
according to the independent claims . 

Further preferred embodiments of the invention will 
emerge — from the oub - claimo. — The embodiments of the 
15 invention which are described below relate not only to 
the method and the device for forming an encrypted 
message but also to the method and the device for 
encrypting an encrypted message. 

20 The components of the invention which are described below 
can be produced in the form of software, that is, by 
means of a computer program, in the form of hardware, 
that is, by means of a special electrical circuit, or in 
any hybrid form, that is, partly in hardware and partly 

25 in software. 

In one embodiment of the invention, there is a method for 
forming an encrypted message whereby the encrypted 
message containo includes communication configuration 
30 data, an Internet-based authentication method is executed 
by using at least one service from a unit in a security 
layer (or link control layer) between a first 
communication unit and a second communication unit, so 
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that at least one pair of cryptographic keys, having at 
least two keys corresponding cryptographically to one 
another, is formed for the first communication unit and 
for the second communication unit. The communication 
5 configuration data of the first communication unit is 

encrypted using at least one cryptographic key of the at 
least one pair of cryptographic keys, thus forming the 
encrypted message. 

10 In a method for decrypting an encrypted message whereby 
said the encrypted message contains includes 
communication configuration data, an Internet-based 
authentication method is executed by using at least one 
service from a unit in a security layer between a first 

15 communication unit and a second communication unit, so 
that at least one pair of cryptographic keys is formed 
for the first communication unit and for the second 
communication unit. The communication configuration data 
of the second communication unit, contained included in 

20 oaid the encrypted message, is determined by decryption 
using at least one cryptographic key of the at least one 
pair of cryptographic keys. 

In another embodiment of the invention, there is a A 
25 device for forming an encrypted message, whereby said the 
encrypted message contains includes communication 
configuration data, has a key generation unit which is 
able to execute an Internet-based authentication method 
by using at least one service from a unit in a security 
30 layer between a first communication unit and a second 
communication unit, so that at least one pair of 
cryptographic keys is formed for the first communication 
unit and for the second communication unit. Furthermore 
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the device has an encryption unit which is able to 
encrypt the communication configuration data by using at 
least one cryptographic key of the at least one pair of 
cryptographic keys, thus forming the encrypted message. 

5 

In another embodiment of the invention, there is aA 
device for decrypting an encrypted message, whereby 
oaid the encrypted message containo includes communication 
configuration data, has a key generation unit which is 

10 able to execute an Internet-based authentication method 
by using at least one service from a unit in a security 
layer between a first communication unit and a second 
communication unit, so that at least one pair of 
cryptographic keys is formed for the first communication 

15 unit and for the second communication unit. Furthermore 
the device has a decryption unit which can decrypt the 
communication configuration data of the second 
communication unit by using at least one cryptographic 
key of the at least one pair of cryptographic keys to 

20 decrypt the encrypted message containing oaid including 
the communication configuration data. 

According to one embodiment of the invention^ the 
Internet-based authentication method is based on an 
25 extensible authentication protocol method. 

Alternatively , in another embodiment, it is possible to 
use any authentication method in which a pair of 
cryptographic keys will be formed and which will use the 
30 services of the security layer without the interposition 
of an IP layer. This clearly means that the Internet- 
based authentication method is produced at the layer 3 
level according to the OSI reference model, that is, at 
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the level of the network layer. 

In other words this means that standardized configuration 
protocols such as those described in [5], [6], [7] or [8] 
5 are used inventively in order to configure a 

communication terminal, preferably a mobile radio 
communication terminal, or to be precise, to provide such 
a terminal with configuration data, which from here on 
will also be called communication configuration data or 
10 communication configuration parameters. 

Said The configuration takes place in a manner not 
provided for in the prior art. 

15 Clearly the standardized configuration protocols are 

cryptographically protected by using cryptographic keys 
which were formed in advance by an Internet-based 
authentication method, in particular preferably an EAP- 
based network authentication method or network 

20 authentication mechanism. 

To put it another way, standardized configuration 
protocols such as DHCP or ModeConfig are protected by 
cryptographic keys formed in the context of prior network 
25 access authentication. 

The communication configuration data can be transmitted 
from the first communication unit to the second 
communication unit by using electronic messages according 
30 to the Internet-based authentication method. 

This embodiment of the invention has the particular 
advantage that the communication protocol used for 
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authentication and key generation can now also be used in 
the message formats to be used for transmitting the 
communication configuration data from the communication 
network to the communication terminal, thus simplifying 
5 the implementation of the method to which the invention 
relates . 

According to another embodiment of the invention, the 
communication configuration data are transmitted from the 
10 first communication unit to the second communication unit 
by using electronic messages according to one of the 
following Internet-based authentication methods 

• protected extensible authentication protocol method, 

• extensible authentication protocol tunneled TLS 
15 authentication protocol method, or 

• protocol for carrying authentication for network 
access method. 

In other words the communication configuration data can 
20 be transmitted according to the method described in [20] , 
[21] or [17] . 

If the EAP-based method itself is used for transmitting 
the communication configuration data, EAP configuration 

25 messages can be protected by means of known tunneling 
methods, such as those described in [20], [21] or [17], 
or by EAP-internal protection mechanisms as in [19] . In 
this connection it is also possible to use the method 
described in [18] as a container in order to transport 

30 the communication configuration data. 

Preferably the first communication unit is a 
communication unit of a communication network element, 
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for preference specifically a communication unit of a 
communication network element in a mobile radio 
communication network according to a 3GPP mobile radio 
standard for example, being for instance a communication 
5 network element which is set up according to UMTS or 

alternatively according to another mobile radio standard 
such as GSM. 

According to another embodiment of the invention, the 
10 second communication unit is a communication terminal, 

for preference specifically a mobile radio communication 
terminal that is set up according to a mobile radio 
communication standard such as 3GPP, for instance 
according to the UMTS or GSM communication standard. 

15 

The method described above is particularly suitable in 
the context of transmitting configuration data over an 
air interface to a mobile radio communication terminal, 
since the communication protocols standardized in this 
20 connection can be used very simply and cost-effectively 
for transmitting the communication configuration 
parameters securely from inside of a communication 
network domain to a mobile radio communication terminal. 

25 According to another embodiment of the invention, the 

communication configuration data is encoded according to 
the protocol format of a protocol for configuring a 
communication terminal, preferably according to the 
protocol format of a protocol for dynamically configuring 

30 a communication terminal, for preference specifically 
according to a protocol format of a dynamic host 
configuration protocol for dynamically configuring a 
communication terminal, as described in [2] for example. 
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Particularly in an EAP-based authentication method, using 
the cryptographic key material generated in the context 
of the EAP-based authentication method for 
5 cryptographically protected transmission of the 

communication configuration data in the context of a DHCP 
communication protocol or ModeConfig communication 
protocol is suitable due to its simplicity- and cost- 
effective implementation . 

10 

Communication configuration data means in this connection 
all the data or parameters which characterize the 
communication properties of a communication terminal in 
the context of a communication session. 

15 

For example^ communication configuration data includes 
data provided by means of the configuration protocol, 
preferably according to the dynamic host configuration 
protocol, for characterizing the communication terminal, 

20 for example the information provided according to the 
BOOTP which was prepared on the BOOTP-based server, in 
particular the IP address of the communication terminal, 
an element known as a subnet mask, an IP address of the 
default gateway, an IP address of the primary DNS server 

25 and/or of the secondary DNS server, an IP address of the 
primary WINS server or an IP address of the secondary 
WINS server, a path to the necessary BOOTP file, a 
communication network domain suffix of the client, that 
is, of the mobile radio communication terminal, an IP 

30 address of the time server, together with a time offset 
from coordinated universal time (CMT) . 



BRIEF DESCRIPTION OF THE DRAWINGS 
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Exemplary embodiments of the invention are shown in the 
drawings and will be explained in greater detail below, 
in which:-r 



5 Figure 1 shows a communication system according to the 

prior art. -7- 



Figures show 2a to 2d are a message flow chart in which 
the individual method steps for transmitting 
10 communication configuration data are shown 

according to a first exemplary embodiment of the 
invent iom — a**d . 



Figures 3a and 3b show a message flow chart in which the 
15 individual method steps for transmitting 

communication configuration data are shown 
according to a second exemplary embodiment of the 
invention . 



20 DETAILED DESCRIPTION OF THE INVENTION 

Fig. 2a to Fig. 2d show a message flow chart 200 
illustrating the exchange .of electronic messages between 
units of a mobile radio communication system set up 
according to the UMTS communication standard. Fig. 2a to 

25 Fig. 2d show specifically a mobile radio communication 

terminal 201, a wireless local area network (WLAN) access 
node computer 202 , a TTLS server 203 and an authorization 
authentication and accounting unit 204 (AAA unit) . 



30 The usual further components of the mobile radio 

communication network according to the UMTS standard, 
especially the units of the core network, as well as the 
further mobile radio communication terminals or fixed 
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network communication terminals that are also provided in 
the communication system so as to provide a communication 
link, are not shown in the message flow chart 200 of Fig. 
2a to Fig. 2d for the sake of simplicity. 

5 

With regard to the message flow, the communication system 
is set up as described in [21] together with the 
enhancement described below. 

10 First the method described in [21] is executed in order 
to establish a TLS tunnel, a unilateral authentication of 
the server 204 being performed on the client, which 
according to this exemplary embodiment is the mobile 
radio communication terminal 201. The message flow is 

15 essentially the same as that described in [21] section 
13.2. 

■ 

Following successful establishment of the TLS tunnel in 
the way to be described in further detail below, an 
20 EAP/MD5 challenge authentication, in other words a 

unilateral authentication of the client, which according 
to this exemplary embodiment is the mobile radio 
communication terminal 201, is performed on the server 
204 . 

25 

As described in [21], the method begins with the access 
point node 202 as in [21] forming an extensible 
authentication protocol Request/Identity message 205 and 
transmitting it to the mobile radio communication 
30 terminal 201. 

In reaction to this the mobile radio communication 
terminal 201 forms and sends an EAP Response/Identity 
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message 206 to the access point node 202, which on 
receiving this message 206 forms a RADIUS Access-Request 
message 207 with the message parameters "XXX-Data-Cipher- 
Suite+ M and "EAP-Response passthrough" , then transmits 
5 said message to the TTLS server 203. 

On receiving the RADIUS Access-Request message 207 the 
TTLS server 203 forms a RADIUS Access-Challenge message 
208 with the parameter EAP-Request /TTLS-Start and 
10 transmits it to the access point node 202. 

On receiving the message 208 the access point node 202 
forms an EAP Request passthrough message 209 and sends 
this to the mobile radio communication terminal 201. 

15 

On receiving the message 209 the mobile radio 
communication terminal 201 forms an EAP Response /TTLS 
message 210 with the parameter "ClientHello" as the 
useful data element and sends this message 210 to the 
20 access point node 202. 

The access point node 202 receives the message 210 and 
forms a RADIUS Access-Request message 211 with the 
parameter M EAP-Response passthrough" as the useful data 
25 element and sends this message 211 to the TTLS server 
203. 

When the TTLS server 203 has received the RADIUS Access- 
Request message 211 and evaluated the useful data element 
30 EAP Response passthrough, the TTLS server 203 forms a 

RADIUS Access-Challenge message 212 and sends this to the 
access point node 202. The RADIUS Access-Challenge 
message 212 contains as useful data elements, that is, as 
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message parameters: "EAP-Request-TTLS " , "ServerHello" , 
"Certificate", "ServerKeyExchange" and "ServerHelloDone" . 

As shown in Fig. 2b, on receiving the message 212 the 
5 access point node 202 forms and transmits an EAP Request 
passthrough message 213 to the mobile radio communication 
terminal 201, which then [forms], according to the method 
described in [21], an EAP Response/TTLS message 214 with 
the parameters "ClientKeyExchange" , "Change-Cipher-Spec", 
10 "Finished" as message parameters and sends the message 
214 to the access point node 202. On receiving the 

message 214 paid the node forms a RADIUS Access-Request 

< 

message 215 with the message parameter "EAP-Response 
passthrough" and transmits this to the TTLS server 203. 

15 

When it receives the message 215 the TTLS server 203 
forms a RADIUS Access-Challenge message 216 with the 
following message parameters: "EAP-Request/TTLS" , 
"Change-Cipher-Spec", "Finished", and sends the message 
20 216 to the access point node 202. When oaid the node 
receives the message 216 it forms an EAP Request 
passthrough message 217 which it transmits to the mobile 
radio communication terminal 201. 

25 On receiving the message 217 the mobile radio 

communication terminal 2 01 forms in response an EAP 
Response/TTLS message 218 with the parameters "{EAP- 
Response/Identity } " and " { XXX-Data-Cipher-Suite+ } " , then 
sends the message 218 to the access point node 202. 

30 

The access point node 202 receives the message 218 and 
forms a RADIUS Access-Request message 219 with the 
element "EAP-Response passthrough". The message 219 is 
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transmitted from the access point node 202 to the TTLS 
server 203, which on receiving the message 219 [forms] a 
RADIUS Access-Request message 220 with the information 
"EAP-Response/Identity" as the useful data element and 
5 sends the message 220 to the AAA server 204. On receiving 
the message 220, said the server responds by forming a 
RADIUS Access-Challenge message 221, paid the message 
containing including the information "EAP-Request/MD5- 
Challenge" as its parameter (cf. Fig. 2c). 

10 

The message 221 is transmitted from the AAA server 204 to 
the TTLS server 203, which for its part on receiving the 
message 221 forms a RADIUS Access-Challenge message 222 
containing including the information 11 EAP- Request /TTLS 11 
15 as its message element together with " { EAP-Request/MD5- 
Challenge}" and " {XXX-Data-Cipher-Suite } " as further 
parameters . 

The message 222 is transmitted from the TTLS server 203 
20 to the access point node 202. When said the node receives 
the message 222 it forms an EAP Request passthrough 
message 223 and transmits it to the mobile radio 
communication terminal . 

25 On receiving the message 223, the mobile radio 

communication terminal 201 forms an EAP Response /TTLS 
message 224 with the information " { EAP-Response/MD5- 
Challenge}" and sends it to the access point node 202. On 
receiving this message said the node forms a RADIUS 

30 Access-Request message 225 with EAP Response passthrough 
and transmits it to the TTLS server 203. 

i 

On receiving the message 225 the TTLS server 203 forms a 
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RADIUS Access-Challenge message 226 with the information 
EAP-Response/MD5-Challenge and transmits the message 226 
to the AAA server 204. 

5 On receiving the message 226 the AAA server 204 forms a 
RADIUS Access-Accept message 227 and sends this to the 
TTLS server 203. When said the server receives the 
message 227 it forms a further RADIUS Access-Accept 
message 228 with the following message parameters: "XXX- 

10 Data-Cipher-Suite", "XXX-Data-Keying-Material" , "EAP- 
Success". The message 228 is transmitted from the TTLS 
server 203 to the access point node 202. When said the 
node receives the message 228 it forms an EAP Success 
passthrough message 229 and transmits it to the mobile 

15 radio communication terminal 201, thus arriving at a 

mutual authentication of the mobile radio communication 
terminal and the AAA server, i.e. the network. 

In order to receive communication configuration data, the 
20 mobile radio communication terminal 201 transmits a 
configuration request message according to the DHCP 
protocol as CP (CFGREQUEST) being the useful data element 
in the protocol format described in [21] in an EAP 
Response /TTLS message 230 and transmits the message to 
25 the access point node 202. When paid the node receives 
the configuration request it again uses the message 
format described in [21] to form a RADIUS Access-Request 
message 231. Said The message 231 has a message parameter 
EAP Response/TTLS passthrough having in addition the 
30 information according to the DHCP message element 
CP (CFGREQUEST) (cf. Fig. 2d). 
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The message 231 transmitted by the access point node 202 
to the TTLS server causes the TTLS server 203 to [lacuna] 
the configuration data available to and provided for the 
mobile radio communication terminal 201, being according 
5 to this exemplary embodiment in particular one or more 
dynamic IP addresses, and transmits oaid the data, using 
the key material formed in the context of the 
authentication method as described above, in a RADIUS 
Access-Challenge message 232 which has as its message 
10 parameters an EAP Request/TTLS with the additional 
parameters according to the DHCP protocol 
"CP (CFG_REPLY) 11 , and sends said message to the access 
point node 202. 

15 The access point node 202 in its turn determines from the 
message 232 the configuration data contained in the 
useful data CP (CFG_REPLY) , in particular the dynamic IP 
address (es) provided for the mobile radio communication 
terminal, and sends the configuration data, in the form 

20 of the DHCP message element "CP (CFGJREPLY) " packed in an 
EAP Response /TTLS message 233, to the mobile radio 
communication terminal 201. 

If the message 233 is successfully transmitted to the 
25 mobile radio communication terminal 201, the latter 

determines the configuration data from the message 233 
and uses said the data as provided for in the control 
program of the mobile radio communication terminal 201. 

30 Clearly transmission of the mobile radio communication 
configuration data takes place after completion of the 
authentication according to the EAP-based authentication 
method described in [21] . In addition to the method 
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described in [21] there is provision for the computer to 
be set up according to [7] in order to give the mobile 
radio communication terminal 201 the ability as client to 
request the communication configuration data by means of 
5 the CFG_REQUEST message and to receive same by means of 
the CFG_REPLY message. 

Except for the message formats described as proprietary 
in [7] the nomenclature, the setup and the parameters are 
10 the same as the customary DHCP format as described in [3] 
for example. 

The communication configuration data is transmitted 
through the established TLS tunnel in a secure 
15 cryptographic manner. 

In the exemplary embodiment, the communication between 
the TTLS server 203 and the node which provides the 
configuration data, such as a DHCP server or a LDAP 
20 server, is not described in further detail in the 
interests of clarity. 

In an alternative embodiment there is provision for the 
communication configuration data to be sent to the mobile 
25 radio communication terminal 201 immediately after 
completion of the mutual authentication, for example 
within the EAP Success message 229. 

A third exemplary embodiment of the invention is shown in 
30 a message flow chart 300 in Fig. 3a and Fig. 3b. 

In this exemplary embodiment the EAP-based authentication 
method is designed according to the PANA method as 
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described in [17] . 

A PANA_Discover (0, 0) message 303 is formed by the PANA 
client 301 according to the protocol described in [17] 
5 and sent to the PAA server 302. On receiving the 

PANA_Di s cove r ( 0 , 0 ) message 303, said server forms a 
response message being PANA_start (x, 0 ) [Cookie] message 
304 and transmits it to the client 301 (cf . Fig. 3a) . 

10 On receiving the message 304 the PANA client 301 forms a 
PANA_start (x, y) [Cookie] message 305 and transmits it to 
the PAA server 302. On receiving the message 305, said 
the server reacts in the context of the EAP-based 
authentication method with a first authentication message 

15 306, being PANA_auth (x+1, y) [EAP{Request } ] , and transmits 
this to the client 301. 

On receiving the message 306 the client 301 forms a 
second authentication message 307 PANA__auth (y+1, x+1) [EAP 
20 {Response}]. The message 307 is transmitted to the PAA 
server 302. 

On receiving the message 307 the PAA server 302 forms a 
third authentication message 308 

25 PANA_auth (x+2, y+1) [EAP{Request } ] and transmits it to the 
client 301, which for its part on receiving the message 
308 forms a fourth authentication message 309 
PANA_auth (y+2, x+2 ) [EAP {Response } ] and transmits it to the 
PAA server, thereby establishing the PAA security 

30 association. 

This method is the same as that described in [17] . 
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Next, as also described in [17], the PAA server 302 forms 
a PANA acknowledgment message 310 

PANA_Success (x+3, y+2) [EAP {Success}, Device-Id, Data- 
Protection, MAC] and transmits it to the client 301, 
5 which is preferably set up as a mobile radio 
communication terminal (cf. Fig. 3b). 

On receiving the message 310 the client 301 forms a PANA 

success acknowledgment message 311 
10 PANA_Success_ack (y+3, x+3) [Device-Id, Data-Protection, 

CP (CFG_Request ) , MAC] and sends this to the PAA server 

302, which for its part, on receiving the message 311 

forms a further PANA message 312 with the requested 

configuration 
15 data and sends it to the client 301 as 

PANA_msg (x+4 , y+3 ) [CP (CFG_Reply ) , MAC] . 

Clearly the embodiment corresponds to the PANA protocol 
according to [17], with the enhancement that the payloads 
20 for transporting the address configuration messages 
according to the DHCP, or alternatively according to 
ModeConfig, have been extended in the context of the 
invention . 

25 In Fig. 3a and Fig. 3b the payloads have also been used 
as configuration payloads according to [7] without 
restricting the general validity. 

The request and response for obtaining the communication 
30 configuration data is cryptographically protected by the 
MAC payload, which is produced by a keyed message digest 
function . 
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The necessary cryptographic key and security parameters, 
that is, the cryptographic key material, or security 
material, are provided by the PANA security association 
(SA) which was generated by means of the EAP 
5 authentication, as described above and dealt with in 
detail in [17] . 
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Claims What is claimed is: 



